We should additionally disallow any extra unparsed tokens before or after the type name.

Do we think using parser.check :EOF is sufficient, or do we want to customize the error a bit? Currently it would raise like expecting token 'EOF', not '100' if you tried to do Bar(Int32)100. But it would raise expecting token: 100 if you tried to parse 100Foo.

Maybe we can just rescue any parse exception an raise a new error that just states that it's an invalid type name. Perhaps the original message can be attached for context.

@straight-shoota Yea that was a good call. Also makes it possible to include the invalid type name in the exception message and properly points to the call site.

Needs a rebase after #10498

What about making it a top-level method?

Yes, I was going to ask about that, too. cf #11117 (comment)

Fine with me. However, is the expectation that parse_type would still return a Path or Generic (Union)? Or would we expect it to return a TypeNode by default now?

Also, I'm assuming this should be restricted to StringLiteral, and probably MacroId, given a SymbolLiteral would be kinda odd/nor could you create one.

Semantics should stay the same, i.e. return Path | Generic.
Restriction to StringLiteral and MacroId sounds fine.

Anything left to do here?

Might want to add test cases for ProcNotation and Metaclass too (however you cannot resolve them yet, pending #11373 and #11375).

Also it is worth noting that technically Self, TypeOf, Splat, and Underscore nodes may be returned here; although the type grammar permits them, TypeOf is allowed only in normal code, whereas (top-level) Splat and Underscore are allowed only in restrictions, so calling #resolve on the returned node is not guaranteed to be meaningful.

Bump. Another review would be 🙏.